Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
A Laboratory Information Management System or Laboratory Integration Management Solution (LIMS) is a software system used in laboratories for the integration of laboratory software and instruments and the management of samples, laboratory users, standards and other laboratory functions such as Quality Assurance (QA) and Quality Control (QC), sample planning, invoicing, plate management, and workflow automation. LIMS implementations may also support information gathering, decision making, calculation, review and release into the workplace and away from the office. More recently, LIMS products are starting to expand into Electronic Laboratory Notebooks, assay data management, data mining and data analysis.
One core function of LIMS is the management of samples. This typically is initiated when a sample is received in the laboratory at which point the sample will be registered in the LIMS. This registration process may involve accessioning the sample and producing barcodes to affix to the sample container. Various other parameters may be recorded as well, such as clinical or phenotypic information corresponding with the sample. The LIMS may then track chain of custody of the sample as well as the sample location. Location tracking often involves assigning the sample to a particular location such as a shelf/rack/box/row/column. Other event tracking may be required such as freeze and thaw cycles that a sample undergoes in the laboratory.
Modern LIMS have implemented extensive configurability as each laboratories needs for tracking additional data points can vary widely. LIMS vendors often cannot make assumptions about what these data tracking needs are and therefore need to be adaptable to each environment. LIMS users may also have regulatory concerns to comply with such as CLIA, HIPAA, GLP and FDA specifications and this can affect certain aspects of sample management in a LIMS solution. One key to compliance with many of these standards is audit logging of all changes to LIMS data, and in some cases a full electronic signature system is required for rigorous tracking of field level changes to LIMS data.
One may configure a LIMS whereby users are assigned roles or groups. Typically the role of a user will dictate their access to specific data records in the LIMS. Each user account is protected by security mechanisms such as a user id and a password. Users may have customized interfaces based on their role in the organization. For example, a laboratory manager might have full access to all of a LIMS functions and data, whereas technicians might have access only to data and functionality needed for their individual work-tasks.
Some LIMS offer some capability for integration with instruments. A LIMS may create control files that are “fed” into the instrument and direct its operation on some physical item such as a sample tube or sample plate. The LIMS may then import instrument results files to extract QC or results data for assessment of the operation on the sample or samples. Data owners may access the resulting stored information at any time.
In order to communicate between the LIMS and an instrument, a device driver, also known as a connectivity driver, may be used. A connectivity driver is a computer program allowing a higher-level computer program, such as the LIMS, to interact with a hardware device, such as an instrument. A connectivity driver typically communicates with the hardware device through a system bus of a computer or a communications device connected with the computer, such as a radio or a network interface to which the hardware device connects. When a higher-level computer program invokes a routine in the connectivity driver, the connectivity driver issues commands to the hardware device. If the hardware device sends data back to the connectivity driver, the connectivity driver may invoke routines in the higher-level computer program and may translate and transfer information received by the hardware device into a format which can be read and used by the higher-level computer program. Connectivity drivers are often hardware-dependent and specific to the higher-level computer program. Connectivity drivers also usually provide interrupt handling required for any necessary asynchronous time-dependent interface between the hardware device and the higher-level computer program.
When developing a connectivity driver for a LIMS, a user typically has to write program code for a computer program from which the connectivity driver is executed for each hardware device for which the LIMS wishes to communicate and interact with. The task of writing program code for a connectivity driver is often laborious and requires many hours of work from a trained computer programmer to complete. Writing program code for a connectivity driver also requires an in-depth understanding of how the hardware device and the higher-level computer program function. Typically, the user of a LIMS does not have the type of training and skills needed to write the program code needed from which the connectivity driver is executed. Thus the task of writing program code for a connectivity driver usually falls to a software engineer.
When developing and building a connectivity driver, the software engineer, or person building the driver, needs to test the connectivity driver to see if it works and can successfully communicate between the LIMS and an instrument, with little or no errors being generated. The testing process, also known as debugging, is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Typically, in order to do debug a connectivity driver, the connectivity driver needs to be in communication with both the LIMS and the instrument for which the connectivity driver is designed to interface with. Since these types of instruments are often found in a laboratory environment, and are rather expensive to use, the time available for the software engineer to debug the connectivity driver is rather limited. As a result, either the instrument for which the connectivity driver was designed to interface with needs to be offline for a substantial amount of time, which may cost the laboratory to incur losses in revenue, or the software engineer may need to debug the connectivity driver in a short amount of time, which may lead to not all of the “bugs,” or defects, within the connectivity driver to be found or fixed.
It would be desirable to provide a simplified method for developing and building connectivity drivers which allows for a complete debugging of the connectivity driver without having to take an instrument offline for a substantial amount of time.